home *** CD-ROM | disk | FTP | other *** search
/ Aminet 2 / Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso / Aminet / dev / amos / AMOSList0993.lzh / AMOSLIST / 000211_amos-request@svcs1.digex.net_Mon Sep 20 13:14:37 1993.msg < prev    next >
Internet Message Format  |  1993-10-03  |  2KB
  1. Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AA05101
  2.   (5.65c/IDA-1.4.4 for <mcox@access.digex.com>); Mon, 20 Sep 1993 13:14:33 -0400
  3. Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
  4.     id AA03090; Mon, 20 Sep 93 13:11:05 -0400 (from amos-request@svcs1.digex.net for mcox@access.digex.com)
  5. Received: by svcs1.digex.net id AA07560
  6.   (5.65c/IDA-1.4.4 for amos-list-out); Mon, 20 Sep 1993 12:52:33 -0400
  7. Received: from access.digex.net by svcs1.digex.net with SMTP id AA07556
  8.   (5.65c/IDA-1.4.4 for <amos-list@svcs1.digex.net>); Mon, 20 Sep 1993 12:52:29 -0400
  9. Received: from sun2.nsfnet-relay.ac.uk by access.digex.net with SMTP id AA01712
  10.   (5.65c/IDA-1.4.4 for <amos-list@access.digex.net>); Mon, 20 Sep 1993 12:52:26 -0400
  11. Via: uk.ac.rutherford.informatics; Mon, 20 Sep 1993 17:51:41 +0100
  12. Received: from cedar by inf.rl.ac.uk; Mon, 20 Sep 93 17:51:31 BST
  13. Date: Mon, 20 Sep 93 17:51:28 BST
  14. From: mas@inf.rl.ac.uk
  15. Message-Id: <9309201651.AA06633@cedar>
  16. To: amos-list@access.digex.net
  17. Subject: Re: Pro Compiler Oddity
  18. X-Sun-Charset: US-ASCII
  19. Content-Length: 1080
  20. Status: RO
  21.  
  22.  
  23. >   In an executable file, all "hunks" (file sections) need to have a size that
  24. > is a multiple of 4.  If the two banks that got a size adjustment were not
  25. > multiples of 4 (the size, not the bank number), that would be why.  (Although
  26. > why the compiler would store each bank in a separate hunk is beyond me; it
  27. > would make more sense to just put them all in the same hunk.)
  28. > 
  29. >   --Andy Church
  30.  
  31. I believe I read that the reason for putting in seperate hunks was that if
  32. you use one hunk it would all need to load into one contiguous lump of memory,
  33. where as by this method the program could still run even if memory had
  34. become slightly fragmented but the pieces still fitted into the fragments
  35. available.
  36.  
  37. The original Amos Compiler does indeed only use one hunk to hold everything,
  38. so that might explain why it works when Pro compiler does not if Andy is
  39. right about hunks. From memory I think Pro compiler still only uses one
  40. hunk to store all the banks, one for the program itself, and one for something
  41. else (possibly the library code or something like that)
  42.  
  43. Martin.
  44.  
  45.  
  46.